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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present specification gives examples of QoS signalling flows for resource reservation to provide end-to-end QoS. 
The flows are used as bases of developing QoS related protocol descriptions for new and existing specifications. 

The present specification adds detailed flows of Service Based Local Policy (SBLP) procedures over the Go and Gq 
interfaces and their relationship with the bearer level signalling flows over the Gn interface. 

The calls flows depicted in this Technical Specification represent usual cases, i.e. not all situations are covered. Detailed 
information provided in TS 29.207 [7] shall be taken into consideration. 

The present specification also describes the mapping of QoS parameters among SDP, UMTS QoS parameters, and QoS 
authorization parameters. 
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Release as the present document. 
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Protocol (RTCP) Bandwidth". 
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[12] 3GPP TS 29. 209: "Policy control over Gq interface". 

[13] IETF RFC 3388: "Grouping of Media Lines in the Session Description Protocol (SDP) ". 

[14] IETF RFC 3524: "Mapping of Media Streams to Resource Reservation Flows" . 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and in 3GPP TS 
29.207 [7] apply. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 



AF 

COPS 

DEC 

DRQ 

IMS 

PDF 

REQ 

RPT 

SBLP 



Application Function 

Common Open Policy Service protocol 

COPS DECision message 

COPS Delete ReQuest state message 

IP Multimedia CN Subsystem 

Policy Decision Function 

COPS REQuest message 

COPS RePorT state message 

Service Based Local Policy 



Autiiorize QoS resources 



4.1 



Authorize QoS resources at AF session establishment 



This clause covers the Authorize QoS resources procedure to be used when an AF session is established. 
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UE 



GGSN 



PDF 



AF 



1 . Trigger 



2. Define connection 
info 



3. Diameter AAR 



4. Token generation and 
session authorization 



6. AF session signalling 



5. Diameter AAA 



Legend: 



Mandatory 
Optional 



1 . The AF receives an internal or external trigger to set up a new AF session. 

2. The AF may identify the connection information needed (e.g. IP address of the IP flow(s), port numbers to 
be used etc.). 

3. The AF requests the authorization token from the PDF by sending a Diameter AAR for a new Diameter 
session. The AF may instruct the PDF to request the full service information from the AF at resource 
reservation. The AF may also forward the part of or the entire service information at this stage in order to 
define the QoS resource authorisation. 

4. The PDF authorizes the possibly received service information. The PDF generates the Authorization 
Token. 

5. An authorization token is sent to the AF. 

6. The Authorization token may be passed to the UE within AF session signalling. 

Figure 4.1 : Authorize QoS resources at session establishment 
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4.2 Authorize QoS resources at AF session modification 

This clause covers the Authorize QoS resources procedure at AF session modification. 



PDF 



AF 



1 . Trigger 



2. Define connection 
info 



3. Diameter AAR 



4. session autinorization 



Legend: 



Mandatory 



5. Diameter AAA 



1 . The AF receives an internal or external trigger to modify the service information for an existing AF 
session. 

2. The AF may identify the connection information needed (e.g. IP address of the IP flow(s), port numbers to 
be used etc.). 

3. The AF sends a Diameter AAR for an existing Diameter session and includes updated service information. 

4. The PDF authorizes the received service information. The PDF may need to approve or remove the QoS 
commit (see Clauses 6.1 and 6.2, respectively) or perform a Session modification initiated SBLP 
authorization decision (see Clause 6.6) due to the updated service information. 

5. The PDF answers with a Diameter AAA. 

Figure 4.2: Authorize QoS resources at AF session modification 



5 Resource reservation flow with Service-based local 

policy 

This clause describes a resource reservation flow with service based local policy. The service based local policy is done 
via exchange of information through the Go and Gq interfaces. The Go and Gq interfaces allow the service based local 
policy and QoS interworking information to be requested by the GGSN from a PDF and the AF. 
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UE 












f 

1 . Mappi 
SDI para 
to UMTS 
V 


ngof 

meters 

QoS 


J 



SGSN 



2. PDP context 
activation req 



12. PDP context 
activation resp. 



GGSN 



3. Create PDP 
context req 



PDF 



4. COPS REQ 



AF 



5. Diameter RAR 




7. Authorize QoS 
resources 



8. COPS DEC 



9. Policy 
Enforcement 



1 1 . Create PDP 
context resp 



10. COPSRPT 



13. Diameter RAR 




Legend: 

► Optional 



Mandatory 



1 . The UE may use SDI or application specific settings in order to define tine UMTS QoS parameter needed 
to request a PDP context. 

2. Thie IJE sends a PDP context activation request to the SGSN. The UE shall include binding information in 
the PDP context activation message to associate the PDP context bearer with policy information. 

3. The SGSN carries out the procedures identified in 3GPP TS 23.060 [4] related to the PDP context 
activation and sends a Create PDP context request to the GGSN. 

4. The GGSN receives the PDP context activation request with the binding information. The GGSN uses the 
authorisation token in order to localise the PDF. The GGSN sends a COPS REQ message to the PDF and 
includes the binding information. 

5. A PDF generated authorization tol<en enables the PDF to identify the authorisation status information. The 
PDF sends an authorisation request to that AF, if instructed by the AF in the initial authorisation request 
from the AF. 

6. If step 5 happens, the AF sends the service information to the PDF. 

7. The PDF performs the authorization decision. 

8. The decision taken by the PDF is returned via the CQPS DEC message. The DEC message includes the 
policy information to be used by the GGSN in order to perform the policy-based admission control. 

9. The GGSN enforces the PDF policy decision on the IP flows based on the received authorization 
information from the PDF for the media components carried by the PDP context. 

10. The GGSN sends CQPS RPT message back to the PDF and reports its success or failure in carrying out 
the PDF decision. 
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1 1 . The GGSN accepts the PDP context request based on the results of the authorisation policy decision 
enforcement. If the requested QoS parameters are not within the authorized QoS, the GGSN downgrades 
the requested UIVITS QoS parameters. 

12. The SGSN sends an Activate PDP Context Accept message to the UE indicating that the PDP context has 
been activated and that the QoS requirements have been authorized for both downlink and uplink. 

13. The PDF may send an indication for the successful bearer establishment, which contains the received 
GPRS charging information to theAF. 

1 4. If step 1 3 happens, the AF sends an answer back to the PDF. 

Figure 5.1 : Resource reservation flow with service based local policy 



6 Other flows over Go and Gq interfaces 

6.1 Approval of QoS commit 

Through the Approval of QoS Commit procedure the PDF makes a final decision to enable the allocated QoS resource 
for the authorized IP flows of the media component (s) if the QoS resources are not enabled at the time they are 
authorized by the PDF, or if previously disabled IP flow(s) or media components are resumed. 





GGSN 




PDF 




AF 




















1 










1 . Trigger 


^ 2. Diameter AAR 
















3. PDF 










approves the 
QoS commit 










^ ) 






4. COPS 


DEC 














7. Diameter AAA 




5. GGSN opens 
the gates 

V J 








6. CO 


PSRPT 





















Legend: 

► Optional 



Mandatory 



6 

7 



The AF receives an internal or external trigger. 

The AF sends a Diameter AAR to the PDF, requesting that gates shall be opened. 

The PDF approves the QoS Commit. 

The PDF sends COPS DEC message(s) to the GGSN to open the "gates" e.g. enable the use of the 

authorised QoS resources. 

The GGSN receives the COPS DEC message{s) and opens the "gates" e.g. enables the use of the 

authorised QoS resources. 

The GGSN sends COPS RPT message(s) back to the PDF. 

The PDF sends a Diameter AAA to the AF. This may trigger further actions in the AF. 

Figure 6.1.1 : Approval of QoS Commit 
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6.2 



Removal of QoS commit 



The "Removal of QoS commit" procedure is used when the AF decides to disable IP flow(s) or media component(s), 
e.g. when a session is released and the related IP flows are removed from a PDP context that multiplexes IP flows from 
several sessions. 



GGSN 



PDF 



AF 



1 . Trigger 



2. Diameter AAR 



3. PDF 
removes the 
QoS Commit 



4. COPS DEC 



5. GGSN closes 
the related gate 



6. COPS RPT 



7. Diameter AAA 



Legend: 

► Optional 



Mandatory 



1 . The AF receives an internal or external trigger to disable the flow. 

2. The AF sends a Diameter AAR to the PDF, requesting that gates shall be closed. 

3. The PDF removes the QoS Commit. 

4. The PDF sends the COPS DEC message{s) to the GGSN to close the relevant media IP flow gate(s), 
leaving the possible related RTCP gate(s) open to keep the connection alive. 

5. The GGSN receives the COPS DEC message{s) and closes the requested gate(s). 

6. The GGSN sends the COPS RPT message{s) back to the PDF. 

7. The PDF sends a Diameter AAA back to the AF. 



Figure 6.2.1 : Removal of QoS commit 



6.3 



Revoke authorization for GPRS and IP resources 



The "Revoke Authorization for GPRS and IP resources" procedure is used e.g. upon session release or upon session 
redirection of the only or last session of a given client handle (PDP context) or upon SIP final error response initiated 
after bearer establishment. The PDF decision of "Revoke Authorization for UMTS and IP Resources" shall be sent as a 
separate decision to the GGSN corresponding to the previous "Authorize QoS Resources" request. 
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6.3.1 AF initiated session release 

Figure 6.3.1 presents the "Revoke Authorization for UMTS and IP Resources" at Network initiated session release (of 
the only or last session of a given client handle) for both the Mobile Originating (MO) side and the Mobile Terminating 
(MT) side. 



GGSN 



PDF 



AF 



1 . Trigger 



2. Diameter STR 



3. PDF starts timer 



4. timer expires. PDF removes 
the authorization for the 
affected IP flow(s) 



5. COPS DEC 



6. GGSN disables 
the autlnorisation 



7. PDP context deactivation 



Legend: 

► Optional 



8. COPS RPT 



10. COPSDRO 



9. Diameter STA 



Mandatory 



6. 

7. 

8. 

9. 
10. 



The AF receives an internal or external trigger for a session release. 

The AF sends session termination request to the PDF to initiate revocation of the authorisation 

PDF starts timer. 

The timer expires but the PDF has not been notified that the affected PDP context(s) have been modified 

or deactivated. The PDF removes the authorisation for the affected IP flow(s) of this session, which it 

authorized previously. 

If step 4 occurs, the PDF sends COPS DEC message(s) to the GGSN including client handle(s), which 

identifies the PDP context(s) to be deactivated. 

The GGSN receives the COPS DEC message, and disables the use of the authorized QoS resources. 

The GGSN initiates deactivation of the PDP context(s) used for the IP multimedia session, in case the UE 

has not done it before. 

GGSN sends RPT message back to the PDF. 

The PDF sends session termination answer to the AF. 

The GGSN sends COPS DRQ message(s) to the PDF. 

Figure 6.3.1 : Revoke authorization for GPRS and IP resources - 
at Mobile initiated session release or Network initiated session release 
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6.4 



Indication of PDP Context Release 



The "Indication of PDP Context Release" procedure is used upon the release of a PDP Context that was established 
based on authorisation from the PDF. 



SGSN 



GGSN 



1. Delete PDP 
context req. 



4. Delete PDP 
context resp. 



PDF 



2. COPS DRQ 



AF 



3. PDF may remove the 
authorization for the 
corresponding media 
components 



Legend: 

► Optional 



Mandatory 



5. Diameter ASR 



6. Diameter ASA 



7. Diameter STR 



8. Diameter STA 



5a. Diameter RAR 



6a. Diameter RAA 



7a. Diameter AAR 



8a. Diameter AAA 



> 



If all IP flows 
within AF 
session are 
affected. 



If not all IP 
flows within 
^ AF session 
are affected. 



1 . The SGSN deactivates the PDP context carrying IP flow(s) of media component(s) by sending the Delete 
PDP Context Request message to the GGSN. 

2. The GGSN sends a COPS DRQ message to the PDF. 

3. The PDF receives the COPS DRQ message and the PDF may remove the authorization for the media 
component(s) with the client handle corresponding to that PDP context. 

4. The GGSN sends the Delete PDP Context Response message to the SGSN to acknowledge the PDP 
context deletion. 

The following steps shall be performed separately for each AF session that is affected by the PDP context release: 

If all IP flow(s) within the AF session are affected by the PDP context release: 

5. The PDF indicates the session abort to the AF by sending an abort session request to the AF if the PDP 
context was the last one for the session. 

6. The AF responds by sending an abort session answer to the PDF. 

7. The AF sends session termination request to the PDF to indicate that the session has been terminated. 

8. The PDF responds by sending a session termination answer to the AF. 

If not all IP flow(s) within the AF session are affected by the PDP context release: 
5a. The PDF indicates the PDP context release to the AF by sending an RAR. 

6a. The AF responds by sending an RAA to the PDF. 

7a. The AF may send an AAR to the PDF to update the session information. 

8a. If step 7a occurs, the PDF responds by sending a AAA to the AF. 

Figure 6.4.1 : Indication of PDP Context Release 
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Figure 6.4.2 presents the case when the GGSN initiates the release of a PDP context, i.e. after an error condition has 
been detected in GGSN. 



SGSN 



GGSN 



2. Delete PDP 
context req. 



3. Delete PDP 
context resp. 



PDF 



1.C0PSDRQ 



AF 



4. PDF may remove the 
authorization for the media 
component{s) 



Legend: 

► Optional 



Mandatory 



5. Diameter ASR 



6. Diameter ASA 



7. Diameter STR 



8. Diameter STA 



5a. Diameter RAR 



6a. Diameter RAA 



7a. Diameter AAR 



8a. Diameter AAA 



> 



If all! P flows 
within AF 
session are 
affected. 



If notalllP 
V flows within 
^ AF session 

are affected. 



The GGSN sends a COPS DRQ message to the PDF. 

The GGSN deactivates the PDP context carrying IP flow(s) of media component(s) by sending the Delete 

PDP Context Request message to the SGSN. 

The SGSN sends the Delete PDP Context Response message to the GGSN to acknowledge the PDP 

context deletion. 

The PDF receives the COPS DRQ message and the PDF may remove the authorization for the media 

component(s) authorized for this client handle. 



The following steps shall be performed separately for each AF session that is affected by the PDP context release: 

If all IP flows within an AF session are affected by the PDP context release: 

5. The PDF indicates the session abort to the AF by sending an abort session request to the AF if the PDP 
context was the last one for the session. 

6. The AF responds by sending an abort session answer to the PDF. 

7. The AF sends session termination request to the PDF to indicate that the session has been terminated. 

8. The PDF responds by sending a session termination answer to the AF. 

If not all IP flows within an AF session are affected by the PDP context release: 

5a. The PDF indicates the PDP context release to the AF by sending an RAR: 

6a. The AF responds by sending an RAA to the PDF. 

7a. The AF may send an AAR to the PDF to update the session information. 

8a. If step 7a occurs, the PDF responds by sending a AAA to the AF. 

Figure 6.4.2: Indication of GGSN-initiated PDP Context Release 
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Figure 6.4.3 presents the case when the PDF initiates the release of a PDP context. This may occur due to an internal 
error or overload condition within the PDF, or if the PDF decides to terminate AF sessions due to a shortage of bearer 
resources. 



£75/ 



3GPP TS 29.208 version 6.5.0 Release 6 



17 



ETSI TS 129 208 V6.5.0 (2005-09) 



SGSN 



GGSN 



PDF 



AF 



1. PDF receives 
internal trigger to 
release a PDP 
context 



2. COPS DEC 



3. GGSN disables 
the authorization 



4. Delete PDP context 
req. 



5. Delete PDP context 
resp. 



6. COPS RPT 



7. COPS DRO 



8. Diameter ASR 



9. Diameter ASA 



10. Diameter STR 



1 1 . Diameter STA 



8a. Diameter RAR 



9a. Diameter RAA 



10a. Diam. AAR 



11a. Diam. AAA 



If all IP flows 
V within AF 



session are 
affected. 



If not all IP 
flows within 
S~ AF session 
are affected. 



Legend: 

► Optional 



Mandatory 



1 . The PDF receives an internal trigger to disable a PDP context. The PDF removes the authorization for the 
IP flow(s) within this PDP context, which it authorized previously. 

2. The PDF sends COPS DEC message to the GGSN including client handle, which identifies the PDP 
context to be deactivated. 

3. The GGSN receives the COPS DEC message, and disables the use of the authorized QoS resources. 

4. The GGSN initiates deactivation of the PDP context. 

5. The GGSN receives delete PDP context response from SGSN. 

6. The GGSN sends a COPS RPT message back to the PDF. 

7. The GGSN sends COPS DRQ message to the PDF. 

The following steps shall be performed separately for each AF session that is affected by the PDP context release: 

If all IP flows within the AF session are affected by the PDP context release: 

8. The PDF indicates the session abortion to the AF by sending an abort session request. 

9. The AF responds by sending an abort session answer to the PDF. 

10. The AF sends session termination request to the PDF to indicate that the session has been terminated 

1 1 . The PDF responds by sending a session termination answer to the AF. 
If not all IP flows within the AF session are affected by the PDP context release: 

8a. The PDF indicates the PDP context release to the AF by sending an RAR. 

9a. The AF responds by sending an RAA to the PDF. 



£75/ 



3GPP TS 29.208 version 6.5.0 Release 6 1 8 ETSI TS 1 29 208 V6.5.0 (2005-09) 

10a. The AF may send an AAR to the PDF to update the session information. 

11a. If step 1 0a occurs, the PDF responds by sending a AAA to the AF. 

Figure 6.4.3: Indication of PDF-initiated PDP Context Release 

6.5 Modification of PDP Context 

The "Modification of PDP Context" procedure is used when a PDP Context is modified such that the requested QoS 
falls outside of the limits that were authorized at PDP context activation (or last modification) or such that the 
maximum bit rate (downlink and uplink) is downgraded to kbit/s. In these cases, the GGSN communicates with the 
PDF as described below. 

6.5.1 Authorization of PDP Context IVIodification 

Figure 6.5.1 presents the "Modification of PDP Context" when the UMTS QoS which were authorized at PDP context 
activation (or last modification) has been changed. 



£75/ 



3GPP TS 29.208 version 6.5.0 Release 6 



19 



ETSI TS 129 208 V6.5.0 (2005-09) 



SGSN 



GGSN 



1 . Update PDP 
context req. 



PDF 



2. COPS REQ 



AF 



H 3. Diameter RAR 
4. Diameter RAA 



5. Authorize QoS 

resource 

modification 



6. COPS DEC 



7. Policy 
Enforcement 



9. Update PDP 
context resp. 



8. COPS RPT 



Legend: 

► Optional 



Mandatory 



A request to modify the PDP context carrying the IP flows of media component(s), of which at least one 

may have been modified or removed, is indicated by sending the Update PDP Context Request message 

to the GGSN with the changed UMTS QoS parameters. 

If the GGSN supports a Local Policy Decision Point{LPDP), it can consult the local policy decision stored 

in the LPDP before sending the COPS REQ message to the PDF. In case the requested QoS is within the 

already authorized QoS and the binding information is not changed, the GGSN does not need to send an 

authorization request to the PDF and proceeds to step 7. Qtherwise, the GGSN sends a CQPS REQ 

message to the PDF. 

If the PDF receives the COPS REQ message, it performs an authorization decision according to the 

requested modification. If the AF has instructed earlier that the PDF needs to contact the AF In bearer 

modification, the PDF sends a re-authorization request to the AF. 

If step 3 happens, the AF responds to the re-authorisation request. 

If the PDF has received a COPS REQ message in step 2, the PDF performs the authorization decision. 

If the PDF has received a COPS REQ message in step 2, the decision taken by the PDF is returned via 

the COPS DEC message. The DEC message includes the policy information to be used by the GGSN in 

order to perform the policy-based admission control. 

The GGSN enforces the policy decision based on the authorization information cached on the GGSN 

LPDP or received from the PDF for the IP flows of media component(s) carried by the PDP context. 

If step 6 has happened, the GGSN sends COPS RPT message back to the PDF and reports its success or 

failure in carrying out the PDF decision and notifies state changes if any. 

The Update PDP Context Response message is sent to the SGSN to acknowledge the PDP context 

modification. 

Figure 6.5.1 : Authorization of PDP Context IVIodification 



6.5.2 Indication of PDP Context Modification 

Figure 6.5.2 presents the "Indication of PDP Context Modification" procedure to both the Mobile Originating (MO) 
side and the Mobile Terminating (MT) side when the maximum bit rate (downlink and uplink) for the PDP context is 
modified to and from kbit/s. 
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SGSN 



GGSN 



PDF 



1. Update PDP 
context req. 



3. Update PDP 
context resp. 



2. COPS RPT 



AF 



4. Diameter RAR 



5. Diameter RAA 



Legend: 

► Optional 



Mandatory 



The SGSN modifies the streaming or conversional PDP context carrying tlie IP flows of media 
component(s) to or from kbits/s by sending the Update PDP Context Request message to the GGSN. 
The GGSN sends a COPS RPT message to the PDF notifying the PDP context modification. 

The GGSN sends the Update PDP Context Response message to the SGSN to acl<nowledge the PDP 

context modification. 

If the AF has instructed the PDF earlier that the PDF needs to contact the AF when the bandwidth of the 

PDP context is modified to l<bit/s, the PDF sends a re-authorization request to the AF. 

If step 4 happens, the AF sends a re-authorisation answer back to the PDF. If the PDP context is modified 

to kbit/s, the authorization may be kept or removed depending on operator"s policies. 

Figure 6.5.2: Indication of PDP Context Modification 
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6.6 



Session modification initiated SBLP authorization decision 



The GGSN receives an unsolicited authorization decision from the PDF, when a session is modified without adding or 
removing media components or IP flows (refer to 3GPP TS 29.207 [7]) , i.e. when the binding information of the AF 
session remains unchanged. The authorization update operation through the Go interface, described in figure 6.6.1, is 
identical in the originating and terminating cases. If the existing QoS of the PDP context exceeds the updated authorised 
QoS and the UE does not modify the PDP context accordingly, the GGSN shall perform a network initiated PDP 
context modification to reduce the QoS to the authorised level. 



GGSN 



PDF 



AF 



1 . Diameter AAR 



2. Authorize 
QoS resource 
modification 



3.. COPS DEC 



4. QoS Authorization 

Update. 

Start of Timer 



5. PDP context 
update 



Legend: 
► 



Optional 
Mandatory 



6. COPS RPT 



7. Diameter AAA 



The AF sends a Diameter AAR to the PDF to indicate the change in the session information 

The PDF analyses the session information and updates the authorization accordingly. 

The PDF sends a COPS DEC message to the GGSN to indicate the change of the authorised QoS 

resources (e.g. bandwidth) and/or the update of packet classifiers (e.g. port numbers). 

If the session modification is related to packet classifiers, the COPS DEC message indicates the 

installation of the new gate in replacement of the previous gate. 

Note: The gate opening may be sent in the same decision; in that case, the GGSN opens the related 

gate(s) and the procedure continues with step 6. 

When the session modification is related to QoS authorization, the GGSN updates the QoS authorization 

information of the session and starts a timer to supervise the PDP context update. 

If the existing QoS of the PDP context exceeds the updated authorised QoS and the UE does not modify 

the PDP context accordingly, the GGSN sends an Update PDP Context Request message to the SGSN 

after the expiry of the timer. 

The GGSN sends a COPS RPT message back to the PDF. 

The PDF sends an AAA to the AF. 



Figure 6.6.1 : Authorization update upon session modification 
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7 QoS parameter mapping 

7.0 Overview of QoS parameter mapping 

The AF derives information about the service from the SDI or from other sources. The AF passes service information to 
the PDF. The PDF notes and authorizes the IP flows described within this service information by mapping from service 
information to Authorized IP QoS parameters for transfer to the GGSN via the Go interface. The GGSN will map from 
the Authorized IP QoS parameters to the Authorized UMTS QoS parameters. 

The UE derives the Authorized UMTS QoS parameters in an application specific manner. It should use information 
from the AF session signalling and SDI for that purpose. If SDP is used as SDI, the UE should apply the mapping rules 
within this specification. The UE shall use the received authorization token as criterion to decide if SBLP is applied. If 
the UE contains an IP BS manager, IP QoS parameters are also generated. 

Upon receiving the PDP context activation or modification, the GGSN shall compare the UMTS QoS parameters 
against the Authorized UMTS QoS parameters. If the request lies within the limits authorized by the PDF, the PDP 
context activation or modification shall be accepted. 

Figure 7.0 indicates the network entities where QoS mapping functionality is performed. This mapping is performed by: 

1 . If SBLP is applied then the AF may map from SDI within the AF session signalling to service information 
passed to the PDF over the Gq interface. The mapping is application specific. If SDP is used as SDI, the AF 
should apply the mapping described in Clause 7.1.0. For IMS, the mapping rules in Clause 7.1.0 shall be used at 
the P-CSCF. 

2. The PDF shall map from the service information received over the Gq interface to the Authorized IP QoS 
parameters that shall be passed to the GGSN via the Go interface. The mapping is performed for each flow 
identifier. Upon a request from the GGSN, the PDF combines per direction the individual Authorized IP QoS 
parameters per flow identifier that are identified by the binding information (see clause 7.1.1). 

3. The UE derives UMTS QoS parameters and, if an IP BS manager is present, IP QoS parameters from the AF 
session signalling in an application specific manner for each flow identifier. The IP and UMTS QoS parameters 
should be generated according to application demands and recommendations for conversational (3GPP TS 
26.236 [6]) or streaming applications (3GPP TS 26.234 [5]). IF SDP is used as SDI, e.g. for IMS, the UE should 
apply Clause 7.2. 1. If SBLP is applied, i.e. the UE has received an authorization token, and SDP is used as SDI, 
the UE should also apply mapping rules for the authorised QoS parameters in Clause 7.2.2 to derive the 
maximum values for the different requested bit rates and traffic classes. In case the UE multiplexes several IP 
flows onto the same PDP context, it has to combine their IP and UMTS QoS parameters. If an IP BS manager is 
present, the Translation/Mapping function maps the IP QoS parameters to the corresponding UMTS QoS 
parameters. 

4. The GGSN shall map from the Authorized IP QoS parameters received from PDF to the Authorized UMTS QoS 
parameters (see clause 7.1.2). 

5. The GGSN shall compare the UMTS QoS parameters of the PDP context against the Authorized UMTS QoS 

parameters (see clause 7.1.3). 

The mapping that takes place in the UE and the network should be compatible in order to ensure that the GGSN will be 
able to correctly authorize the session. 
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3)UE 



Application 



IP BS Manager 



______ J 



Translation / 
Mapping 
function 



UMTS BS 
Manager 



AF session signalling . 
possibly with SDI 



GGSN 



PEP (Policy 
Enforcement Point) 



IP BS Manager 



4) Translation / 
Mapping 
function 



5) UMTS BS 
Manager 



1)AF 



Go 



Gq (Service 
information) 



2) PDF 

(Policy Decision Function) 



A ► 



Signalling path 



NOTE 1 : The AF may derive the Service information from the AF session signalling. 

NOTE 2: Service Information on Gq interface to Authorized IP QoS parameters mapping. 

NOTE 3: The UE may derive IP QoS parameters, requested UMTS QoS parameters mapping and Authorized 

UIVITS QoS parameters from the AF session signalling. 
NOTE 4: Authorized IP QoS parameters to Authorized UMTS QoS parameters mapping. 
NOTE 5: UMTS QoS parameters with Authorized UMTS QoS parameters comparison. 

Figure 7.0: Framework for QoS mapping between AF and GPRS 



7.0.1 QoS parameter mapping for IMS 

Within the IMS, session establishment and modification involves an end-to-end message-exchange using SIP/SDP with 
negotiation of media attributes (e.g. Codecs) as defined in 3GPP TS 24.229 [3] and 3GPP TS 24.228 [2]. If the IMS 
applies Service Based Local Policy (SBLP), as specified in 3GPP TS 29.207 [7], then the P-CSCF shall provide service 
information derived from the relevant SDP information to the PDF via the Gq interface. The P-CSCF shall apply the 
mapping rules in Clause 7.1.0 to derive service information from SDP. The SIP/SDP message will also have been 
passed on to the UE, where the UE will perform its own mapping from the SDP parameters and application demands to 
some UMTS QoS Parameters in order to populate the requested QoS field within the PDP context activation or 
modification. If SBLP is applied, i.e. the UE has received an authorization token, then the UE should also derive the 
Authorized UMTS QoS parameters from the SDP parameters. If the UE contains an IP BS manager IP QoS parameters 
are also generated. 

7.1 .0 SDP parameters to service information mapping in AF 

The mapping described in this clause is mandatory for the P-CSCF and should also be applied by other AFs if the SDI 
is SDP. 

When a session is initiated or modified the P-CSCF shall use the mapping rules in table 7.1.0.1 for each SDP media 
component to derive a Media-Component-Description AVP from the SDP Parameters. Furthermore, the P-CSCF shall 
map information about the grouping of media lines into resource reservation flows into the Flow-Grouping AVP as 
specified in table 7.1.0.3. 
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Table 7.1.0.1 : Rules for derivation of service information within IVIedia-Component-Description AVP 

from SDP media component 



service information per 
Media-Component- 
Description AVP 
(NOTE 1 ; Note 7) 


Derivation from SDP Parameters 
(see NOTE 2) 


IMedia-Component- 
Number 


ordinal number of the position of the "m=" line in the SDP 


AF-Appllcation-ldentifier 


The AF-Application-Identif ier AVP may be supplied or omitted, depending on 
the application. For IMS, if the AF-Application-Identif ier AVP is supplied, 
its value should not demand application specific bandwidth or QoS class 
handling. However, if an IMS application is capable of handling a QoS 
downgrading, the AF-Application-Identif ier AVP may be used to demand 
application specific bandwidth or QoS class handling. 


IVIedia-Type 


The Media Type AVP shall be included with the same value as supplied for 
the media type in the "m=" line. 


Flow-Status 


IF port in m-line = THEN 
Flow-Status := REMOVED; 
ELSE 

IF a=recvonly THEN 

IF <SDP direction> = mobile originated THEN 

Flow-Status := ENABLED_DOWNLINK; (NOTE 4) 
ELSE /* mobile terminated */ 

Flow-Status := ENABLED_UPLINK; (NOTE 4) 
ENDIF; 
ELSE 

IF a=sendonly THEN 

IF <SDP direction> = mobile originated THEN 

Flow-Status := ENABLED_UPLINK; (NOTE 4) 
ELSE /* mobile terminated */ 

Flow-Status := ENABLED_DOWNLINK; (NOTE 4) 
ENDIF; 
ELSE 

IF a=inactive THEN 

Flow-Status :=DISABLED; 
ELSE /* a=sendrecv or no direction attribute */ 

Flow-Status := ENABLED (NOTE 4) 
ENDIF; 
ENDIF; 
ENDIF; 
ENDIF; 
(NOTE 5) 


Max-Requested- 
Bandwidth-UL 


IF <SDP direction> = mobile terminated THEN 
IF b=AS : <bandwidth> is present THEN 

Max-Requested-Bandwidth-UL:= <bandwidth> * 1000; /* Unit is bit/s 
ELSE 

Max-Requested— Bandwidth-UL : = <Operator specific setting>, 
or AVP not supplied; 
ENDIF; 
ELSE 

Consider SDP in opposite direction 
ENDIF 


Max-Requested- 
Bandwidth-DL 


IF <SDP direction> = mobile originated THEN 
IF b=AS:<bandwidth> is present THEN 

Max-Requested-Bandwidth-DL:= <bandwidth> * 1000; /* Unit is bit/s 
ELSE 

Max-Requested— Bandwidth-DL ; = <Operator specific setting>, 
or AVP not supplied; 
ENDIF; 
ELSE 

Consider SDP in opposite direction 
ENDIF 


RR-Bandwidth 


IF b=RR: <bandwidth> is present THEN 

RR-Bandwidth := <bandwidth>; 
ELSE 

AVP not supplied 
ENDIF; 
(NOTE 3; NOTE 6) 


RS-Bandwidth 


IF b=RS: <bandwidth> is present THEN 

RS-Bandwidth: = <bandwidth>; 
ELSE 

AVP not supplied 
ENDIF; 
(NOTE 3: NOTE 6) 


Media-Sub-Component 


Supply one AVP for each Flow Identifier within the media component. The 
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Flow identifiers are derived according to Annex D of 3GPP TS 29.207 [7] 
The encoding of the AVP is described in Table 7.1.0.2 



N0TE1 
NOTE 2 
NOTES 
NOTE 4 



NOTE 5: 



NOTE 6: 
NOTE 7: 



The encoding of the service information is defined in TS 29.209 [12]. 

The SDP parameters are described in RFC 2327 [9]. 

The "b=RS:" and "b=RR:" SDP bandwidth modifiers are defined in RFC 3556 [10]. 

As an operator policy to disable forward and/or backward early media, the Flow-Status may be downgraded 

before a SIP dialogue is established, i.e. until a 200 OK(INVITE) is received. The Value 'DISABLED' may be 

used instead of the Values 'ENABLED_UPLINK' or 'ENABLED_DOWNLINK'. The Values 'DISABLED', 

'ENABLED_UPLINK' or 'ENABLED_DOWNLINK' may be used instead of the Value 'ENABLED'. 

If the SDP answer is available when the session information is derived, the direction attributes and port number 

from the SDP answer shall be used to derive the flow status. However, to enable interoperability with SIP clients 

that do not understand the inactive SDP attribute, if a=inactive was supplied in the SDP offer, this shall be used 

to derive the flow status. If the SDP answer is not available when the session information is derived, the 

direction attributes from the SDP offer shall be used. 

Information from the SDP answer is applicable, if available. 

The AVPs may be omitted if they have been supplied in previous service Information and have not changed, as 

detailed in TS 29.209 [12]. 
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Table 7.1.0.2: Rules for derivation of IVIedia-Sub-Component AVP from SDP media component 



Gq service information 
per Media-Sub- 
Component AVP 
(NOTE 1, NOTE 5) 



Derivation from SDP Parameters 
(see NOTE 2) 



Flow-Number 



derived according to Annex C of 3GPP TS 29.207 [7] 



Flow-Status 



AVP not supplied 



Max-Requested- 
Bandwidth-UL 



AVP not supplied 



Max-Requested- 
Bandwidth-DL 



AVP not supplied 



For uplink and dowlink direction, a Flow-Description AVP shall be provided 
unless no IP Flows in this direction are described within the media 
component . 

The SDP direction attribute (NOTE 4) indicates the direction of the media 
IP flows within the media component as follows : 
IF a=recvonly THEN (NOTE 3) 

IF <SDP direction> = mobile originated THEN 

Provide only downlink Flow-Description AVP 
ELSE /* mobile terminated */ 

Provide only uplink Flow-Description AVP 
ENDIF; 
ELSE 

IF a=sendonly THEN (NOTE 3) 

IF <SDP direction> = mobile originated THEN 
Provide only uplink Flow-Description AVP 
ELSE /* mobile terminated */ 

Provide only downlink Flow-Description AVP 
ENDIF; 
ELSE /* a=sendrecv or a=inactive or no direction attribute */ 

Provide uplink and downlink Flow-Description AVPs 
ENDIF; 
ENDIF; 
For RTCP IP flows uplink and downlink Flow-Description AVPs shall be 
provided irrespective of the SDP direction attribute. 

The uplink destination address shall be copied from the "c=" line of 

downlink SDP. (NOTE 6) 

The uplink destination port shall be derived from the "m=" line of downlink 

SDP. (NOTE 6) 

The downlink destination address shall be copied from the "c=" line of 

uplink SDP. (NOTE 6) 

The downlink destination port shall be derived from the "m=" line of uplink 

SDP. (NOTE 6) 

Uplink and downlink source adresses shall either be derived from the prefix 

of the destination address or be wildcarded by setting to "any", as 

specified in TS 29.209 [12] . Source ports shall not be supplied. 

Proto shall be derived from the transport of the "m=" line. For "RTP/AVP" 

proto is 17 (UDP) . 



Flow-Description 



The Flow-Usage AVP shall be supplied with value "RTCP" if the IP flow(s) 
described in the Media-Sub-Component AVP are used to transport RTCP. 
Otherwise the Flow-Usage AVP shall not be supplied. RFC 2327 [9] specifies 
how RTCP flows are described within SDP. 



Flow-Usage 



NOTE 1 : The encoding of the service information is defined in TS 29.209 [1 2]. 

NOTE 2: The SDP parameters are described in RFC 2327 [9]. 

NOTE 3: If the SDP direction attribute for the media component negotiated in a previous offer-answer exchange was 

sendrecv, or if no direction attribute was provided, and the new SDP direction attribute sendonly or recvonly is 

negotiated in a subsequent SDP offer-answer exchange, uplink and downlink Flow-Description AVPs shall be 

supplied. 
NOTE 4: If the SDP answer is available when the session information is derived, the direction attributes from the SDP 

answer shall be used to derive the flow description. However, to enable interoperability with SIP clients that do 

not understand the inactive SDP attribute, if a=inactive was supplied in the SDP offer, this shall be used. If the 

SDP answer is not available when the session information is derived, the direction attributes from the SDP offer 

shall be used. 
NOTE 5: The AVPs may be omitted if they have been supplied in previous service information and have not changed, as 

detailed in TS 29.209 [12]. 
NOTE 6: If the session information is derived from an SDP offer, the required SDP may not yet be available. The 

corresponding Flow Description AVP shall nethertheless be included and the unavailable fields (possibly all) 

shall be wildcarded. 
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Table 7.1.0.3: Rules for mapping SDP information about the grouping of media lines into resource 

reservation flows into the Flow Grouping AVP 



Flow-Grouping AVP 
(N0TE1) 


Derivation from SDP Parameters 
(see NOTE 2) 


Flow Grouping 


For each SDP "a=group: SRF" SDP line, a Flow Grouping AVP shall be 
generated. (NOTE 3) 


Flows 


For each identification tag within "a=group: SRF" SDP line, a Flows AVP 
containing a Media-Component-Number AVP identifying the corresponding m- 
line shall be generated. (NOTE 3) No Flow-Number AVP shall be supplied 
within the Flows AVP. 


NOTE 1 : The encoding of the service information is defined in TS 29.209 [12]. 
NOTE 2: The SDP parameters are described in RFC 2327 [9]. 

NOTE 3: The SDP 'group' attribute is defined in RFC 3388 [13]. The 'SRF' semantics attribute within this grouping 
framework is defined in RFC 3524 [14]. 



7.1.1 



Gq service information to Autinorized IP QoS parameters mapping in 
PDF 



The QoS authorization is to be based on the parameters Maximum Authorized QoS Class and Maximum Authorized 
Data Rate UL/DL. 

When a session is initiated or modified the PDF shall use the mapping rules in table 7.1.1.1 to derive the Authorized IP 
QoS parameters Maximum Authorized Data Rate DL/UL and the Maximum Authorized QoS Class from the service 
information. In the case of forking, the various forked responses may have different QoS requirements for the IP flows 
of the same media component. Each Authorized IP QoS Parameter shall be set to the highest value requested for the IP 
flow(s) of that media component by any of the active forked responses. These values are derived by the rules in table 
7.1.1.1 
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Table 7.1.1.1 : Rules for derivation of the lUlaximum Authorized Data Rates 
and IVIaximum Authorized QoS Class per flow identifier in the PDF 



Authorized IP QoS 

Parameter per flow 

identifier 



Derivation from service information 
(see note 4) 



IVIaximum Authorized Data 
Rate DL (l\/lax_DR_DL) and 
UL (l\/lax_DR_UL) per flow 
identifier 



IF AF-Application-Identif ier AVP demands application specific data rate 
handling THEN 

Max_DR_UL : = as defined by application specific algorithm; 
iyiax_DR_DL ; = as defined by application specific algorithm; 



ELSE 



IF not RTCP flow(s) according to Flow-Usage AVP THEN 
IF Flow-Status = REMOVED THEN 
Max_DR_UL:= 0; 
Max_DR_DL:= 0; 
ELSE 

IF uplink Flow Desription AVP is supplied THEN 
IF Max-Requested-Bandwidth-UL is present THEN 

Max_DR_UL:= Max-Requested-Bandwidth-UL ; 
ELSE 

Max_DR_UL : = as set by the operator; 
ENDIF 
ELSE 

Max_DR_UL:= 0; 
ENDIF; 

IF downlink Flow Desription AVPs is supplied THEN 
IF Max-Requested-Bandwidth-DL is present THEN 

Max_DR_DL : = Max-Requested-Bandwidth-DL; 
ELSE 

Max_DR_DL;= as set by the operator; 
ENDIF 
ELSE 

Max_DR_DL:= 0; 
ENDIF; 
ENDIF; 
ENDIF; 

ELSE /* RTCP IP flow(s) */ 
IF RS-Bandwidth is present and 
RR-Bandwidth is present THEN 

Max_DR_UL:= (RS-Bandwidth + RR-Bandwidth); 
Max_DR_DL:= (RS-Bandwidth + RR-Bandwidth); 
ELSE 

IF Max-Requested-Bandwidth-UL is present THEN 
IF RS-Bandwidth is present and 

RR-Bandwidth is not present THEN 

Max_DR_UL:= MAX[0.05 * Max-Requested-Bandwidth-UL, 
RS-Bandwidth] ; 
ENDIF; 

IF RS-Bandwidth is not present and 
RR-Bandwidth is present THEN 

Max_DR_UL:= MAX[0.05 * Max-Requested-Bandwidth UL, 
RR-Bandwidth] ; 
ENDIF; 
IF RS-Bandwidth and RR-Bandwidth is not present THEN 

Max_DR_UL:= 0.05 * Max-Requested-Bandwidth„UL ; 
ENDIF; 
ELSE 

Max_DR_UL ; = as set by the operator; 
ENDIF; 

IF Max-Requested-Bandwidth-DL is present THEN 
IF RS-Bandwidth is present and 

RR-Bandwidth is not present THEN 

Max_DR_DL:= MAX[0.05 * Max-Requested-Bandwidth-DL, 
RS-Bandwidth] ; 
ENDIF; 

IF RS-Bandwidth is not present and 
RR-Bandwidth is present THEN 

Max_DR_DL:= MAX[0.05 * Max-Requested-Bandwidth-DL, 
RR-Bandwidth] ; 
ENDIF; 
IF RS-Bandwidth and RR-Bandwidth is not present THEN 

Max_DR_DL:= 0.05 * Max-Requested-Bandwidth-DL; 
ENDIF; 
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ELSE 

Max_DR_DL: = as set by the operator; 
END IF; 
ENDIF; 
ENDIF; 

ENDIF 


Maximum Authorized QoS 

Class [MaxClass] per flow 

identifier 

(see notes 1 , 2 and 3) 


IF AF-Application-Identif ier AVP demands application specific QoS Class 
handling THEN 

MaxClass := as defined by application specific algorithm; 
ELSE 

IF Media-Type is present THEN 

IF (only uplink Flow Desription AVPs are supplied for all IP 

flows of the AF session, which have media type "audio" or "video" 
and no flow usage "RTCP", or 

only downlink Flow Desription AVPs are supplied for all IP 
flows of the AF session, which have media type "audio" or "video" 
and no flow usage "RTCP") THEN 
MaxClassDerivation: =B; /* streaming*/ 
ELSE 

MaxClassDerivation: =A; /* conversational*/ 
ENDIF; 

CASE Media-Type OF 

"audio": MaxClass := MaxClassDerivation 

"video": MaxClass := MaxClassDerivation 

"application": MaxClass :=A; /*conversational*/ 

"data": MaxClass :=E; /*interactive with priority 3*/ 

"control": MaxClass:=C; /*interactive with priority 1*/ 

/*new media type*/ 
OTHERWISE: MaxClass :=F; /*background*/ 
END; 
ELSE 

MaxClass := as defined by by operator; 
ENDIF; 
ENDIF; 


NOTE 1 : The Maximum Authorized QoS Class for a RTCP IP flow is the same as for the corresponding RTP media IP 
flow. 

NOTE 2: When audio or video IP flow (s) are removed from a session, the parameter MaxClassDerivation shall keep the 
originally assigned value. 

NOTE 3: When audio or video IP flow(s) are added to a session, the PDF shall derive the parameter MaxClassDerivation 
taking into account the already existing media IP flow(s) within the session. 

NOTE 4: The encoding of the service information is defined in TS 29.209 [12]. If AVPs are omitted within a Media- 
Component-Description AVP or Media-Sub-Component AVP of the service information, the corresponding 
information from previous service information shall be used, as specified in TS 29.209 [12]. 



The PDF shall per ongoing session store the Authorized IP QoS parameters per flow identifier. 

When the GGSN requests the Authorized UMTS QoS parameters for an activated/modified PDP Context carrying IP 
flows of media component(s), the PDF shall use the rules in table 7.1.1.2 to calculate the Authorized IP QoS parameters 
per Client Handle. 
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Table 7.1.1.2: Rules for calculating the Maximum Authorized Data Rates 
and Maximum Authorized QoS Class per Client Handle in the PDF 



Authorized IP 

QoS Parameter 

per Client 

Handle 


Calculation Rule 


Maximum 
Authorized Data 
Rate DL and UL 
per Client 
Handle 


Maximum Authorized Data Rate DL/UL per Client Handle is the sum of all Maximum 
Authorized Data Rate DL/UL for all the flow identifiers associated with that 
Client Handle. 

IF Maximum Authorized Data Rate DL/UL per Client Handle > 16000 kbps THEN 

Maximum Authorized Data Rate DL/UL per Client Handle = 16000 kbps /* See 
3GPP TS 23.107 [8] */ 

END; 


Maximum 
Authorized QoS 
Class per Client 
Handle 


Maximum Authorized QoS Class per Client Handle = MAX [Maximum Authorized QoS 
Class per flow identifier among all the flow identifiers associated with that 
Client Handle. 

(The MAX function ranks the possible Maximum Authorized QoS Class values as 
follows: "A" > "B" > "C" > "D" > "E" > "F") /* See 3GPP TS 29.207 [7]) */ 



7.1 .2 Authorized IP QoS parameters to Authorized UMTS QoS 
parameters mapping in GGSN 

The Translation/Mapping function in the GGSN shall derive the Authorized UMTS QoS parameters from the 
Authorized IP QoS parameters received from the PDF according to the rules in table 7. 1.2. 

Table 7.1.2: Rules for derivation of the Authorized UMTS QoS Parameters per PDP context 
from the Authorized IP QoS Parameters per Client Handle in GGSN 



Authorized 

UMTS QoS 

Parameter per 

PDP context 



Derivation from Authorized IP QoS Parameters 



Maximum 
Authorized 
Bandwidth DL 
and UL per PDP 
context 



Maximum Authorized Bandwidth DL/UL per PDP context 
Rate DL/UL per CLient Handle 



Maximum Authorized Data 



Maximum 
Authorized 
Traffic Class per 
PDP context 



IF Maximum Authorized QoS Class = "A" THEN 

Maximum Authorized Traffic Class = "Conversational" 

ELSEIF Maximum Authorized QoS Class = "B" THEN 

Maximum Authorized Traffic Class = "Streaming" 

ELSEIF Maximum Authorized QoS Class = "C" THEN 

Maximum Authorized Traffic Class = "Interactive"; 
Maximum Authorized Traffic Handling Priority = "1"; 

ELSEIF Maximum Authorized QoS Class = "D" THEN 

Maximum Authorized Traffic Class = "Interactive"; 
Maximum Authorized Traffic Handling Priority = "2"; 

ELSEIF Maximum Authorized QoS Class = "E" THEN 

Maximum Authorized Traffic Class = "Interactive"; 
Maximum Authorized Traffic Handling Priority = "3"; 

ELSE Maximum Authorized Traffic Class = "Background" 
ENDIF ; 



7.1 .3 Comparing UMTS QoS Parameters against the Authorized UMTS 
QoS parameters in GGSN 

Upon receiving a PDP context activation containing binding information, the GGSN requests the Authorized QoS 
information from the PDF, and may request the Authorized UMTS information if a PDP context containing binding 
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information is modified (see 3GPP TS 29.207 [7] for details). The GGSN compares the requested UMTS QoS 
parameters against the corresponding Authorized UMTS QoS parameters received via the translation/mapping function. 
If all the requested parameters lie within the limits, the PDP context activation or modification shall be accepted. I.e. the 
following criteria shall be fulfilled: 

• the requested Guaranteed Bitrate DL/UL (if the requested Traffic Class is Conversational or Streaming) or 
Maximum Bitrate DL/UL (if the requested Traffic Class is Interactive or Background) is less than or equal to 
Maximum Authorized data rate DL/UL; and 

• the requested Traffic Class is less than or equal to Maximum Authorized Traffic Class. 

If any of the requested parameters do not lie within their respective limit, the GGSN shall downgrade the requested 
UMTS QoS parameters. 

7.2 QoS parameter mapping in the UE 

Figure 7.2 indicates the entities participating in the generation of the requested QoS parameters when activate or modify 
a PDP Context in the UE. The steps are: 

1. The Application provides the UMTS BS Manager, possibly via the IP BS Manager and the Translation/Mapping 
function, with relevant information to perform step 2 or step 4. (Not subject to standardization within 3GPP). 

2. If needed, information from step 1 is used to access a proper set of UMTS QoS Parameters. See 

3GPP TS 26.236 [6] for Conversational Codec AppHcations and 3GPP TS 26.234 [5] for Streaming Codec 
Applications. 

3. If SDP is available then the SDP Parameters should give guidance for the UMTS BS Manager (possibly via the 
IP Manager and the Translation/Mapping function) , according to the rules in clause 7.2.1, to set the Maximum 
Bitrate UL/DL and the Guaranteed Bitrate UL/DL. Furthermore if the SDP Parameters are received in an IMS 
context in which SBLP is applied, i.e. an authorization token has been received, the Maximum Authorized 
Bandwidth UL/DL and Maximum Authorised Traffic Class should be derived according to the rules in clause 
7.2.2. 

4. A set of UMTS QoS Parameters values from step 2 (or directly from step 1) is possibly merged together with the 
Maximum Bitrate UL/DL and the Guaranteed Bitrate UL/DL from step 3. The result should constitute the 
requested UMTS QoS Parameters. If the PDP Context is activated or modified in an IMS context in which SBLP 
is applied, the UE should check that the requested Guaranteed Bitrate UL/DL or requested Maximum Bitrate 
UL/DL (depending on the requested Traffic Class) does not exceed the Maximum Authorized Bandwidth 
UL/DL derived in step 3. Furthermore, if the UE has implemented the mapping rule for Maximum Authorized 
Traffic Class, as defined in clause 7.2.2, the UE should check that the requested Traffic Class does not exceed 
the Maximum Authorised Traffic Class derived in step 3. 
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Figure 7.2: Framework for generating requested QoS parameters in thie UE 
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7.2.1 SDP to UMTS QoS parameter mapping in UE 

If SDP Parameters are available, then before activating or modifying a PDP Context the UE should check if the SDP 
Parameters give guidance for setting the requested UMTS QoS Parameters. The UE should use the mapping rule in 
table 7.2.1 to derive the Maximum and Guaranteed Bitrate DL/UL from the SDP Parameters. 

Table 7.2.1 : Recommended rules for derivation of the requested Maximum 
and Guaranteed Bitrate DL/UL per media component in the UE 



UMTS QoS Parameter per 
media component 


Derivation from SDP Parameters 


IVIaximum Bitrate DL/UL 

and 

Guaranteed Bitrate 

DL/UL per media 

component 


/* Check if the media use codec (s) */ 

IF [ (<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming */ 

IF a= ("sendonly" or "recvonly") THEN 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media 
component as specified in reference [5] ; 
/* Conversational as default !*/ 
ELSE 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media 
component as specified in reference [6] ; 
END IF ; 

/* Check for presence of bandwidth attribute for each media component */ 
ELSEIF b=AS :<bandwidth-value> is present THEN 
IF media stream only downlink THEN 

Maximum Bitrate DL = Guaranteed Bitrate DL =<bandwidth-value >; 
ELSEIF mediastream only uplink THEN 

Maximum Bitrate UL = Guaranteed Bitrate UL =<bandwidth-value >; 
ELSEIF mediastreams both downlink and uplink THEN 

Maximum Bitrate DL = Guaranteed Bitrate DL =<bandwidth-value >; 
Maximum Bitrate UL = Guaranteed Bitrate UL =<bandwidth-value >; 
ENDIF; 
ELSE 

/* SDP does not give any guidance ! */ 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media component as 

specified by the UE manufacturer; 

ENDIF ; 



7.2.2 SDP parameters to Autlnorized UMTS QoS parameters mapping in 
UE 

If the PDP Context is activated or modified and SBLP is applied, i.e. an authorization token has been received, then the 
UE should use the mapping rules in table 7.2.2.1 for all applications using SDP to derive the Maximum Authorized 
Bandwidth UL/DL per flow identifier. 

Table 7.2.2.1 also has a mapping rule for derivation of Maximum Authorized Traffic Class per flow identifier which 
applies for session initiation and modification. 

In future releases this mapping rule may change. 

In the case of forking, the various forked responses may have different QoS requirements for the same IP flows of a 
media component. When the Authorized UMTS QoS Parameters are used by the UE, they shall be set equal to the 
highest values requested for the IP flows of that media component by any of the active forked responses. The UE should 
use the mapping rule in table 7.2.2.1 for each forked response. 
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Table 7.2.2.1 : Rules for derivation of the IVIaximum Authorized Bandwidth DL/UL 
and the lUlaximum Authorized Traffic Class per flow identifier in the UE 



Authorized UIVITS QoS 

Parameter per flow 

identifier 



Derivation from SDP Parameters 
(see note 4) 



IVIaximum Authorized 
Bandwidth DL 
(Max_BW_DL) and UL 
(Max_BW_UL) per flow 
identifier (see note 5) 



IF SBLP is applied THEN 

/* The Direction of the IP flow(s) identified by the flow identifier */ 

IF a=recvonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction;= downlink; 
ELSE /* mobile terminated */ 

Direction:= uplink; 
ENDIF; 
ELSE; 

IF a=sendonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction; = uplink; 
ELSE /* mobile terminated */ 

Direction;= downlink; 
ENDIF; 
ELSE /*sendrecv, inactive or no direction attribute*/ 

Direction: =both; 
ENDIF; 
ENDIF; 

/* Max_BW_UL and Max_BW_DL */ 

IF media IP flow(s) THEN 

IF bAs=AS: <bandwidth> is present THEN 
IF Direction=downlink THEN 
Max_BW_UL:= 0; 
Max_BW_D L : = bAs ; 
ELSE 

IF Direction=uplink THEN 
Max_BW_UL:= bas; 
Max_BW_DL:= 0; 
ELSE /*Direction=both*/ 
Max_BW_UL:= bas; 
Max_BW_DL:= bas; 
ENDIF; 
ENDIF; 
ELSE 

bw:= as set by the UE manufacturer; 
IF Direction=downlink THEN 
Max_BW_UL:= 0; 
Max_BW_DL:= bw; 
ELSE 

IF Direction=uplink THEN 
Max_BW_UL:= bw; 
Max_BW_DL:= 0; 
ELSE /*Direction=both*/ 
Max_BW_UL:= bw; 
Max_BW_DL:= bw; 
ENDIF; 
ENDIF; 
ENDIF; 
ELSE /* RTCP IP flow(s) */ 

IF bRs=RS: <bandwidth> and bRE=RR: <bandwidth> is present THEN 
Max_BW_UL:= (bRs + bRR) / 1000; 
Max_BW_DL:= (bRs + bsR) / 1000; 
ELSE 

IF bAs=AS: <bandwidth> is present THEN 

IF bRs=RS ; <bandwidth> is present and bRR=RR; <bandwidth> is not 
present THEN 

Max_BW_UL:= MAX[0.05 * bis, bRs / 1000]; 
Max_BW_DL:= MAX[0.05 * bxs, bRs / 1000]; 
ENDIF; 

IF bRs=RS ; <bandwidth> is not present and bRR=RR; <bandwidth> is 
present THEN 

Max_BW_UL:= I»X[0.05 * bis, bRR / 1000]; 
Max_BW_DL:= 1^1AX[0.05 * bas, Wr / 1000]; 
ENDIF; 

IF bRs=RS: <bandwidth> and bRR=RR: <bandwidth> is not present THEN 
Max„BW_UL:= 0.05 * bas; 
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Authorized UIVITS QoS 

Parameter per flow 

identifier 


Derivation from SDP Parameters 
(see note 4) 




Max_BW_DL:= 0.05 * bas; 
ENDIF; 
ELSE 

Max_BW_UL ; = as set by the UE manufacture; 
Max_BW_DL;= as set by the UE manufacture; 
ENDIF; 
ENDIF; 
ENDIF; 

ELSE 

No authorization is done ; 
ENDIF ; 


Maximum Authorized 
Traffic Class 
[MaxTrafficClass] per 
flow identifier (see 
NOTE1,2and3) 


IF SBLP is applied THEN 

IF (all media IP flows of media type "audio" or "video" for the 
session are unidirectional and have the same direction) THEN 
MaxService := streaming; 
ELSE 

MaxService : = conversational; 
ENDIF; 

CASE <media> OF 

"audio": MaxTraf f icClass ; = MaxService; 

"video": MaxTraf ficClass : = MaxService; 

"application" : MaxTrafficClass : =conversational; 

"data": MaxTraf ficClass : =interactive with priority 3; 

"control": MaxTraf ficClass : =interactive with priority 1; 

/*new media type*/ 

OTHERWISE : MaxTrafficClass : =background; 
END; 
ELSE 

No authorization is done ; 
ENDIF ; 


NOTE 1 : The Maximum Authorized Traffic Class for a RTCP IP flow is the same as for the corresponding RTF media IP 

flow. 
NOTE 2: When audio or video IP flow(s) are removed from a session, the parameter MaxService shall keep the 

originally assigned value. 
NOTE 3: When audio or video IP flow(s) are added to a session, the UE shall derive the parameter IVIaxService taking 

into account the already existing media IP flows within the session 
NOTE 4: The SDP parameters are described in RFC 2327 [9]. 
NOTE 5: The "b=RS:" and "b=RR:" SDP bandwidth modifiers are defined in RFC 3556 [1 0]. 



The UE should per ongoing session store the Authorized UMTS QoS parameters per flow identifier. 

Before activate or modify a PDP context the UE should check that the requested Guaranteed Bitrate UL/DL (if the 
Traffic Class is Conversational or Streaming) or the requested Maximum Bitrate UL/DL (if the Traffic Class is 
Interactive or Background) does not exceed the Maximum Authorized Bandwidth UL/DL per PDP context (calculated 
according to the rule in table 7.2.2.2). If the requested Guaranteed Bitrate UL/DL or the requested Maximum Bitrate 
UL/DL exceeds the Maximum Authorized Bandwidth UL/DL per PDP context, the UE should reduce the the requested 
Guaranteed Bitrate UL/DL or the requested Maximum Bitrate UL/DL to the Maximum Authorized Bandwidth UL/DL 
per PDP context. Furthermore, if the rule in table 7.2.2.1 for calculating Traffic Class per flow identifier is 
implemented, the UE should check that the requested UMTS QoS parameter Traffic Class does not exceed the 
Maximum Authorized Traffic Class per PDP context (calculated according to the rule in table 7.2.2.2). If the requested 
UMTS QoS parameter Traffic Class exceeds the Maximum Authorized Traffic Class per PDP context, the UE should 
reduce the the requested UMTS QoS parameter Traffic Class to the Maximum Authorized Traffic Class per PDP 
context. 
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Table 7.2.2.2: Rules for calculating the Maximum Authorized Bandwidths 
and IVIaximum Authorized Traffic Class per PDP Context in the UE 



Authorized 

UIMTS QoS 

Parameter per 

PDP Context 



Calculation Rule 



IVIaximum 
Authorized 
Bandwidth DL 
and UL per PDP 
Context 



IF SBLP is applied THEN 

Maximum Authorized Bandwidth DL/UL per PDP Context is the sum of all Maximum 
Authorized Bandwidth DL/UL for all the flow identifiers 
associated with that PDP Context ; 

IF Maximum Authorized Bandwidth DL/UL per PDP Context > 16000 kbps THEN 
Maximum Authorized Bandwidth DL/UL per PDP Context = 16000 kbps 
/* See ref [8] */ 

END; 

ELSE 

No authorization is done ; 
ENDIF ; 



IVIaximum 
Authorized 
Traffic Class per 
PDP Context 



IF SBLP is applied THEN 

Maximum Authorised Traffic Class per PDP Context = MAX [Maximum Authorised 
Traffic Class per flow identifier among all the flow identifiers 
associated with that PDP Context] ; 

ELSE 

No authorization is done ; 
ENDIF ; 

(The MAX function ranks the possible Maximum Authorised Traffic Class values i 
follows; Conversational > Streaming > Interactive with priority 1 > Interacti 
with priority 2 > Interactive with priority 3 > R=^>^^^n"H\ 



as 
ve 



Background) 
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Annex A (informative): 

Examples of deriving the IVIaximum Authorized parameters 

from the SDP parameters 



A.1 Example 1 



The relevant SDP parameters (i.e. from which the Maximum Authorized IP QoS and Maximum UMTS QoS Parameters 
are derived) in the downlink direction are assigned the following values: 

Table A.1.1 : Values of the relevant SDP parameters in example 1. 



v=o 

o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM01 

i=Two unidirectional audio and video media and one bidirectional application media 

1=3262377600 3262809600 

m=video 51372 RTP/AVP 31 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

b=AS:128 

b=RR:2300 

b=RS:3000 

a=sendonly 

m=audio 49170 RTP/AVP 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

b=AS:64 

a=sendonly 

m=application 32416 udp wb 

c=IN IP6 2001:0646:000A:03A7:0250:DAFF:FE0E:C6F2 

b=AS:32 

a=landscape 

a=sendrecv 



The IP flows of the session are identified by 5 flow identifiers (see 3GPP TS 29.207 [7] for the definition of a flow 
identifier): 

Flow identifier < 1,1 > identifies the video media IP flows downlink and flow identifier <1,2> identifies the 
RTCP IP flows uplink and downlink associated with the video media IP flows. 

Flow identifier <2,1> identifies the audio media IP flows downlink and flow identifier <2,2> identifies the 
RTCP IP flows uplink and downlink associated with the audio media IP flows. 

Flow identifier <3,1> identifies the application media IP flows uplink and downlink. 

In the PDF, the Maximum Authorized IP QoS parameters per flow identifier are assigned the values, according to table 
7.1.1.1, as shown in table A. 1.2: 
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Table A.1.2: The values of the Maximum Authorized IP QoS parameters per flow identifier as 
calculated by the PDF. 







Flow Identifier 




<1,1> 


<1,2> 


<2,1> 


<2,2> 


<3,1> 


Max_DR_DL 


(kbps) 


128 


5.3 


64 


3.2 


32 


Max_DR_UL 


(kbps) 





5.3 





3.2 


32 


MaxClass 


B 


B 


B 


B 


A 



In the UE, the Maximum Authorized UMTS QoS parameters per flow identifier are assigned the values, according to 
table 7.2.2.1, as shown in table A.1.3: 

Table A.1.3: The values of the Maximum Authorized UMTS QoS parameters per flow identifier as 
calculated by the UE. 







Flow Identifier 




<1,1> 


<1,2> 


<2,1> 


<2,2> 


<3,1> 


Max BW DL 


(kbps) 


128 


5.3 


64 


3.2 


32 


Max BW UL 


(kbps) 





5.3 





3.2 


32 


MaxTrafficClass 


streaming 


streaming 


streaming 


streaming 


conversational 



Each pack of IP flow(s) described by a media component must all be carried on the same PDP context. If the UE 
decides to put each media IP flow(s) and its associated RTCP IP flow on dedicated PDP contexts (three PDP contexts 
are needed!), then the UE will calculate the values of the Maximum Authorized Bandwidths per PDP context and the 
Maximum Traffic Class per PDP context, according to table 7.2.2.2, as shown in table A. 1.4: 

Table A.I. 4: The values of the Maximum Authorized UMTS QoS parameters per PDP Context as 
calculated by the UE. 





PDP context # 




1 


2 


3 


Maximum Authorized Bandwidth DL (kbps) 


133.3 


67.2 


32 


Maximum Authorized Bandwidth UL (kbps) 


5.3 


3.2 


32 


Maximum Authorized Traffic Class 


streaming 


streaming 


conversational 



For each of the three PDP context activation requests the GGSN will assign a Client Handle to the PDP context 
activation request and send an Authorization Request message to the PDF containing the Binding Information received 
in the PDP context activation request message. The PDF calculates the values of the Maximum Authorized Data Rate 
per Client Handle and a Maximum Authorized QoS Class per Client Handle, according to table 7.1.1.2, as shown in 
table A. 1.5: 

Table A.I. 5: The values of the Maximum Authorized IP QoS parameters per Client Handle as 
calculated by the PDF. 





Client Handle corresponding to 
PDP context # 




1 


2 


3 


Maximum Authorized Data Rate DL (kbps) 


133.3 


67.2 


32 


Maximum Authorized Data Rate UL (kbps) 


5.3 


3.2 


32 


Maximum Authorized QoS Class 


B 


B 


A 



For each of the three Client Handles the PDF sends these Maximum Authorized IP QoS parameters per Client Handle in 
an Authorization Decision message to the GGSN. The GGSN derives the values of the Maximum Authorized 
Bandwidths per PDP context and the Maximum Traffic Class per PDP context, according to table 7.1.2, as shown in 
table A. 1.6: 
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Table A.1.6: The values of the Maximum Authorized UIVITS QoS parameters per PDP context as 
calculated by the GGSN. 





PDP context # 




1 


2 


3 


Maximum Authorized Bandwidth DL (kbps) 


133.3 


67.2 


32 


IVIaximum Authorized Bandwidth UL (kbps) 


5.3 


3.2 


32 


IVIaximum Authorized Traffic Class 


streaming 


streaming 


conversational 



A.2 Example 2 



The relevant SDP parameters in the downhnk direction are assigned the following values: 
Table A.2.1 : Values of the relevant SDP parameters in example 2. 



v=o 

o=ecsreid 3262464321 3262464325 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM02 

i=Two unidirectional audio streams described by one media component 

1=3262377600 3262809600 

m=audio 49170/2 RTP/AVP 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

b=AS:64 

b=RR:2000 

b=RS:1000 

a=sendonly 



The IP flows of the session are identified by 4 flow identifiers (see 3GPP TS 29.207 [7] for the definition of a flow 
identifier): 

Flow identifier < 1,1 > identifies the audio media IP flows downlink and flow identifier <1,2> identifies the 
RTCP IP flows uplink and downlink associated with these audio media IP flows. 

Flow identifier <1,3> identifies the other audio media IP flows downlink and flow identifier <1,4> identifies 
the RTCP IP flows uplink and downlink associated with these audio media IP flows. 

The PDF calculates the values of the Maximum Authorized IP QoS parameters per flow identifier, according to table 
7.1.1.1, as shown in table A. 2. 2: 

Table A.2.2: The values of the Maximum Authorized IP QoS parameters per flow identifier as 
calculated by the PDF. 





Flow Identifier 




<1,1> 


<1,2> 


<1,3> 


<1,4> 


l\/lax_DR_DL (kbps) 


64 


3.0 


64 


3.0 


Max_DR_UL (kbps) 





3.0 





3.0 


MaxClass 


B 


B 


B 


B 



The UE calculates the values of the Maximum Authorized UMTS QoS parameters per flow identifier, according to 
table 7.2.2.1, as shown in table A.2. 3: 
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Table A.2.3: The values of the Maximum Authorized UIUITS QoS parameters per flow identifier as 
calculated by the UE. 





Flow Identifier 




<1,1> 


<1,2> 


<1,3> 


<1,4> 


Max BW DL (kbps) 


64 


3.0 


64 


3.0 


Max BW UL (kbps) 





3.0 





3.0 


MaxTrafficClass 


streaming 


streaming 


streaming 


streaming 



As all IP flows are described by the same media component the UE must let all IP flows be carried on one PDP context. 
The UE will calculate the values of the Maximum Authorized Bandwidths per PDP Context and the Maximum Traffic 
Class per PDP Context, according to table 7.2.2.2, as shown in table A.2.4: 

Table A.2.4: The values of the lUlaximum Authorized UIUITS QoS parameters per PDP Context as 
calculated by the UE. 





PDP context # 




1 


Maximum Authorized Bandwidth DL (kbps) 


134.0 


Maximum Authorized Bandwidth UL (kbps) 


6.0 


Maximum Authorized Traffic Class 


streaming 



The PDF calculates the values of the Maximum Authorized Data Rate per Client Handle and the Maximum Authorized 
QoS Class per Client Handle, according to table 7.1.1.2, as shown in table A. 2. 5: 

Table A.2.5: The values of the Maximum Authorized IP QoS parameters per Client Handle as 
calculated by the PDF. 





Client Handle corresponding to PDP 
context # 




1 


Maximum Authorized Data Rate DL (kbps) 


134.0 


Maximum Authorized Data Rate UL (kbps) 


6.0 


Maximum Authorized QoS Class 


B 



The GGSN derives the values of the Maximum Authorized Bandwidths per PDP context and the Traffic Class per PDP 
context, according to table 7.1.2, as shown in table A.2.6: 

Table A.2.6: The values of the Maximum Authorized UMTS QoS parameters per PDP context as 
calculated by the GGSN. 





PDP context # 




1 


Maximum Authorized Bandwidth DL (kbps) 


134.0 


Maximum Authorized Bandwidth UL (kbps) 


6.0 


Maximum Authorized Traffic Class 


streaming 
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Annex B (normative): 
Signalling Flows for IMS 



B.1 Authorize QoS resources 

B.1 .1 Authorize QoS resources at originating P-CSCF and PDF at 
IMS session establishment 

This clause covers the Authorize QoS resources procedure at the originating P-CSCF and PDF at IMS session 
establishment. 
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PDF 



P-CSCF 



2. Define down-link 
connection info 



3. SDP 



4. SDP 



5. Define up-link 
connection info 



6. Diameter AAR 



y.Token generation and 
authorize QoS Resources 



9. SDP 



8. Diameter AAA 



Legend: 



Mandatory 



1 . The P-CSCF receives the SDP parameters defined by the originator within an SDP offer in SIP signalling. 

2. The P-CSCF identifies the connection information needed (IP address of the down link IP flow{s), port 
numbers to be used etc.). 

3. The P-CSCF forwards the SDP offer in SIP signalling. 

4. The P-CSCF gets the negotiated SDP parameters from the terminating side through SIP signalling 
interaction. 

5. The P-CSCF identifies the connection information needed (IP address of the up-link media IP flow(s), port 
numbers to be used etc.). 

6. The P-CSCF forwards the derived session information to the PDF and requests an authorization token by 
sending a Diameter AAR for a new Diameter session. 

7. The PDF authorizes every component negotiated for the session. An authorization token is generated by 
the PDF. 

8. The PDF sends the authorization token to the P-CSCF. 

9. Upon successful authorization of the session the SDP parameters and the Authorization token are passed 
to the UE in SIP signalling. 

Figure B.I .1 : Authorize QoS resources at originating PDF 

B.1 .2 Authorize QoS resources at terminating P-CSCF and PDF 
at IIVIS session establishment 

This clause covers the Authorize QoS resources procedure at the terminating P-CSCF and PDF at IMS session 
estabHshment. 
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1.SDP 



P-CSCF 



PDF 



2. Define up-link 
connection info 



3. Diameter AAR 



GGSN 



4. Token generation 



5. Diameter AAA 



8. Define down-link 
connection info 



12. SDP 



9. Diameter AAR 



6. SDP 
7. SDP 



10. Autliorize QoS 
resources 



11. Diameter AAA 



UE 



10. 
11. 
12. 



The P-CSCF receives the SDP parameters defined by the originator. 

The P-CSCF identifies the connection information needed (IP address of the up-link IP flow(s), port 

numbers to be used etc.). 

The P-CSCF requests the Authorisation Token from the PDF by sending a Diameter AAR for a new 

Diameter session. 

An authorization token is generated by the PDF. 

The PDF sends the authorization token to the P-CSCF. 

The P-CSCF sends the SDP offer and the authorization token to the UE- 

The P-CSCF receives the negotiated SDP parameters from the UE. 

The P-CSCF identifies the connection information needed (IP address of the down-link IP flow(s), port 

numbers to be used etc.). 

The P-CSCF forwards the derived service information to the PDF by sending a Diameter AAR for the 

existing Diameter session. 

The PDF authorizes every component negotiated for the session. 

The PDF sends an Diameter AAA to the P-CSCF. 

Upon successful authorization of the session the SDP parameters in the SDP answer are passed to the 

originator. 

Figure B.1.2: Authorize QoS resources at terminating PDF 
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B.1 .3 Authorize QoS resources at IMS session modification 

This clause covers the Authorize QoS resources procedure at IMS session modification both at the originating and 
terminating side. 



PDF 



1.SDP 



6. SDP 



P-CSCF 



2. Identify relevant 
changes in SDP 



3. SDP 



4. SDP 



5. Identify relevant 
changes in SDP 



7. Diameter AAR 



8. session authorization 



Legend: 



Mandatory 



9. Diameter AAA 



1 . The P-CSCF receives the SDP parameters defined by the originator within an SDP offer in SIP signalling. 

2. The P-CSCF identifies the relevant changes in the SDP. 

3. The P-CSCF forwards the SDP offer in SIP signalling. 

4. The P-CSCF gets the negotiated SDP parameters from the terminating side through SIP signalling 
interaction. 

5. The P-CSCF identifies the relevant changes in the SDP. 

6. The P-CSCF forwards the SDP answer in SIP signalling. 

7. The P-CSCF sends a Diameter AAR for an existing Diameter session and includes the derived updated 
service information. 

8. The PDF authorizes the received service information. The PDF may need to approve or remove the QoS 
commit (see Clauses B.3 and B.4, respectively) , revoke the authorization for GPRS and IP resources at 
media component removal (see Clause B.5.2), or perform a Session modification initiated SBLP 
authorization decision (see Clause B.8) due to the updated service information. 

9. The PDF answers with a Diameter AAA. 

Figure B.1.3: Authorize QoS resources at IIVIS session modification 
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B.2 Resource reservation flow with Service-based local 



policy 



Clause 5 applies. 



B.3 Approval of QoS commit 



Through Approval of QoS Commit the PDF makes a final decision to enable the allocated QoS resource for the 
authorized IP flows of the media component (s) if the QoS resources are not enabled at the time they are authorized by 
the PDF or if the media IP flow(s) previously placed on hold are resumed, i.e. the media IP flow(s) of the media 
component that was placed on hold at the time of the resource authorization or at a later stage is reactivated (with SDP 
direction sendrecv, sendonly, recvonly or none direction). 

The Approval of QoS Commit procedure is triggered by the P-CSCF receiving a 200 OK response to an INVITE 
request or a 200 OK response to an UPDATE request within a confirmed dialogue. When receiving those 200 OK 
responses, the PDF shall take the SDP direction attribute in the latest received SDP (either within the 200 OK or a 
previous SIP message) into account when deciding, which gates shall be opened: 

For a unidirectional SDP media component, the Approval of QoS Commit procedure shall not be triggered for 
the possible media IP flows in the opposite direction. 

For an inactive SDP media component, the Approval of QoS Commit procedure shall not be triggered for the 
media IP flows. 

Figure B.3. 1.1 is applicable to the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 



£75/ 



3GPP TS 29.208 version 6.5.0 Release 6 



46 



ETSI TS 129 208 V6.5.0 (2005-09) 



GGSN 



PDF 



P-CSCF 



2. Diameter AAR 



3. PDF approves 
QoS commit 



4. COPS DEC 



5. GGSN opens 
the gates 



6. COPS RPT 



8. . 200 OK 



7. Diameter AAA 



1.200 OK 



Legend: 



Mandatory 



6 

7 
8 



The P-CSCF receives tine 200 OK message complying witti tiie conditions specified in tiie paragraptis 

above. 

Tlie P-CSCF sends a Diameter AAR message to tine PDF, requesting tiiat gates siiail be opened. 

Tlie PDF approves tine QoS Commit. 

Tlie PDF sends COPS DEC message(s) to tiie GGSN to open Vne "gates" e.g. enable tine use of the 

authorised OoS resources. 

The GGSN receives the COPS DEC message{s) and opens the "gates" e.g. enables the use of the 

authorised OoS resources. 

The GGSN sends COPS RPT message(s) bacl< to the PDF. 

The PDF sends a Diameter AAA to the P-CSCF. 

The P-CSCF forwards the 200 OK message. 



Figure B.3.1.1: Approval of QoS Commit to both the IVIobile Originating (MO) side 
and the Mobile Terminating (MT) side 



B.4 Removal of QoS commit 

The "Removal of QoS commit" procedure is used e.g. when a session is released and the related IP flows are removed 
from a PDP context that multiplexes IP flows from several sessions, or when media IP flow(s) of a session are put on 
hold (e.g. in case of a media re-negotiation or call hold). The PDF decision of "Removal of QoS commit" shall be sent 
as a separate decision to the GGSN corresponding to the previous "Authorize QoS Resources" request. 

B.4.1 Removal of QoS commit at Media on Hold 

Media is placed on hold as specified in RFC 3264 [II]. Media modified to become inactive (SDP direction attribute) 
shall also be considered to be put on hold. 

If a bidirectional media component is placed on hold by making it unidirectional, the QoS Commit shall only be 
removed in the deactivated direction. If a media component is placed on hold by making it inactive, the QoS Commit 
shall be removed in both directions. 
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Figure B.4.1.1 presents the "Removal of QoS commit" procedure at media on hold to both the Mobile Originating (MO) 
side and the Mobile Terminating (MT) side. 



GGSN 



PDF 



P-CSCF 



2. SDR answer putting media on hold 



3. Diameter AAR 



4. PDF removes 
the QoS commit for 
the media on hold 



5. COPS DEC 



6. GGSN closes 
the related gate 



7. COPS RPT 



8. Diameter AAA 



1 . SDP answer 
putting media 
on hold 



Legend: 

► 



Mandatory 



1. 

2. 

3. 

4. 
5. 

6. 
7. 
8. 

NOTE 1 : 



The P-CSCF receives an SDP answer putting media on hold within a SIP message. (NOTE 1) 

The P-CSCF forwards the SDP answer putting media on hold within a SIP message. 

The P-CSCF sends a Diameter AAR request to the PDF, requesting that gates shall be closed. 

The PDF removes the OoS commit for the media on hold. 

The PDF sends the COPS DEC message(s) to the GGSN to close the relevant media IP flow 

gate(s), leaving the possible related RTCP gate(s) open to keep the connection alive. 

The GGSN receives the COPS DEC message(s) and closes the requested gate(s). 

The GGSN sends the COPS RPT message(s) back to the PDF. 

The PDF sends a Diameter AAA message back to the P-CSCF. 

This procedure occurs whenever a bidirectional media is made unidirectional or when a media is changed 
to inactive. 



Figure B.4.1.1 : Removal of QoS commit at lUledia on Hold to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 

B.4.2 Removal of QoS commit at media component removal 

Figure B.4.2. 1 presents the "Removal of QoS commit" procedure at media component removal for both the Mobile 
Originating (MO) side and the Mobile Terminating (MT) side. This procedure is optional. In addition, the procedure in 
Clause B.5.2 applies in this situation after timer expiry. 
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GGSN 



PDF 



P-CSCF 



2. SDR answer removing media 
component 



3. Diameter AAR 



4. PDF shall start timer 
and may remove the QoS 
Commit for the media 
component 



5. COPS DEC 



6. GGSN closes 
the related gate 



7. COPS RPT 



8. Diameter AAA 



1 . SDP answer 
removing media 
component 



Legend: 



Mandatory 



1 . The P-CSCF receives an SDP answer removing media component. 

2. The P-CSCF forwards the SDP answer removing media component. 

3. The P-CSCF sends a Diameter AAR to the PDF, requesting that corresponding gates shall be closed. 

4. The PDF shall start timer and may remove the QoS commit for the related IP flow(s) of the media 
component. After timer expiry, Figure B. 5. 1.1 applies. 

5. The PDF sends a COPS DEC message to the GGSN to close the related "gate(s)". 

6. The GGSN receives the COPS DEC message and closes the "gate{s)". 

7. The GGSN sends a COPS RPT message back to the PDF. 

8. The PDF sends a Diameter AAA message back to the P-CSCF. 

Figure B.4.2.1 : Removal of QoS commit at media component removal for both the Mobile Originating 

(MO) side and the Mobile Terminating (MT) side 



B.5 Revoke authorization for GPRS and IP resources 

The "Revoke Authorization for GPRS and IP resources" procedure is used e.g. upon session release or upon session 
redirection of the only or last session of a given client handle (PDF context) or upon SIP final error response initiated 
after bearer establishment. The PDF decision of "Revoke Authorization for UMTS and IP Resources" shall be sent as a 
separate decision to the GGSN corresponding to the previous "Authorize QoS Resources" request. 

B.5.1 Mobile initiated session release / Network initiated session release 

Figure B.5. 1.1 presents the "Revoke Authorization for UMTS and IP Resources" at Mobile initiated session release / 
Network initiated session release (of the only or last session of a given client handle) for both the Mobile Originating 
(MO) side and the Mobile Terminating (MT) side. The session release may be signalled by a SIP BYE message, by a 
SIP CANCEL request, or any SIP 3xx redirect response, or any 4xx, 5xx, or 6xx SIP final error response. 
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GGSN 



PDF 



2. BYE.CANCJEL 
3xx, 4xx, 5xx 



or 6xx 



P-CSCF 



3. Diameter STR 



4. PDF starts timer 



5. timer expires. PDF removes 
the authorization for the 
affected IPflow{s) 



6. COPS DEC 



7. GGSN disables 
the authorization 



8. PDP context 
deactivation 

< 



Legend: 

► 



9. COPS RPT 



11.C0PSDRQ 



Mandatory 



1 0. Diameter STA 



1 . BYE^CANCEL, 
3xx, 4xx, 5xx, or 6xx 



7. 
8. 

9. 
10. 

11. 



SIP BYE message, a SIP CANCEL request, a SIP 3xx redirect response, or any 4xx, 5xx, or 6xx SIP final 

error response is received by the P-CSCF. 

P-CSCF forwards the BYE message, or the SIP 3xx redirect response, a SIP CANCEL request, or any 

4xx, 5xx, or 6xx SIP final error response. 

The P-CSCF sends a session termination request to the PDF to initiate the revocation of the authorization 

PDF starts timer. 

The timer expires, but the PDF has not been notified that the affected PDP context(s) have been modified 

or deactivated to match the revoked authorization. The PDF removes the authorization for the IP flow{s) of 

this session, which it authorized previously. 

If step 5 occurs, the PDF sends the COPS DEC message(s) to the GGSN including the client handle{s), 

which identifies the PDP context(s) to be deactivated. 

The GGSN receives the COPS DEC message, and disables the use of the authorized OoS resources. 

The GGSN initiates the deactivation of the PDP context{s) used for the IP multimedia session, in case the 

UE has not done it before. 

The GGSN sends the COPS RPT message(s) back to the PDF. 

The PDF indicates the result of the authorization revocation by sending a Diameter session termination 

answer to the P-CSCF 

The GGSN sends the COPS DRO message(s) to the PDF. 

Figure B.5.1.1 : Revoke authorization for GPRS and IP resources - 

IVIobile initiated session release / Network initiated session release 

for both Mobile Originating (MO) and Mobile termination side 
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B.5.2 Media component removal 



Figure B.5.2. 1 presents the "Revoke Authorization for UMTS and IP Resources" at the removal of media component(s) 
from an IMS session which is not being released for both the Mobile Originating (MO) side and the Mobile 
Terminating (MT) side. In addition, the procedure in Clause B.4.2 may have been applied before the PDF removes the 
authorization for the affected IP flow(s). 
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GGSN 



PDF 



P-CSCF 



2. SDR removing media 
component(s) 



3. Diameter AAR 



4. PDF starts timer 



I). Diameter AAA 



6. timer expires. PDF removes 
the authorization for the 
affected IP flow(s) 



7. COPS DEC 



8. GGSN disables 
the authorisation 



9. PDF context 
deactivation 



10. COPSRPT 



1 1 . COPS DRO 



12. Diameter ASR 



13. Diameter ASA 



14. Diameter STR 



15. Diameter STA 



12a. Diam. RAR 



13a. Diam. RAA 



14a. Diam. AAR 



15a. Diam. AAA 



1 . SDP removing 
media component(s) 



If all IP flows 
V within AF 
session are 
affected. 



If not all IP 
flows within 
S- AF session 
are affected. 



8. 
9. 
10. 

11. 



A SIP message containing SDP indicating the removal of media component(s) is received by the P-CSCF. 

The P-CSCF forwards the SIP message. 

The P-CSCF sends Diameter AAR to the PDF with modified service information. 

PDF starts timer. 

The PDF send Diameter AAA to P-CSCF 

The timer expires, but the PDF has not been notified that the affected PDP context(s) have been modified 

or deactivated to match the revoked authorization. The PDF removes the authorization for the affected IP 

flow(s), which it authorized previously. 

If step 6 occurs, the PDF sends the COPS DEC message(s) to the GGSN including the client handle{s), 

which identifies the PDP context(s) to be deactivated. 

The GGSN receives the COPS DEC message, and disables the use of the authorized OoS resources. 

The GGSN initiates the deactivation of the PDP context(s), in case the UE has not done it before. 

The GGSN sends the COPS RPT message{s) back to the PDF. 

The GGSN sends the COPS DRO message(s) to the PDF. 
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If step 6 occurs and all IP flows within AF session are affected by PDP context release: 

12. The PDF indicates the bearer removal to the P-CSCF by sending an abort session request to the P-CSCF. 

13. The P-CSCF responds by sending an abort session answer to the PDF. 

14. The P-CSCF sends session termination request to the PDF to indicate that the session has been 
terminated 

1 5. The PDF responds by sending a session termination answer to the P-CSCF. 

If step 6 occurs and not all IP flows within AF session are affected by PDP context release: 
12a. The PDF indicates the PDP context release to the P-CSCF by sending an RAR. 

1 3a. The P-CSCF responds by sending an RAA to the PDF. 

14a. The P-CSCF may send an AAR to the PDF to update the session information. 

1 5a. If step 1 4a occurs, the PDF responds by sending a AAA to the P-CSCF. 

Figure B.5.2.1 : Revoke authorization for GPRS and IP resources - 

media component removal 
for both Mobile Originating (MO) and Mobile Terminating (MT) side 



B.6 Indication of PDP Context Release 

Clause 6.4 applies. 



B.7 IVIodification of PDP Context 

Clause 6.5 applies. 



B.8 Session modification initiated SBLP authorization 
decision 

The GGSN receives an unsolicited authorization decision from the PDF, when a session is modified without adding or 
removing media lines from SDP (refer to 3GPP TS 29.207 [7]). The procedures in Clause 6.6 apply. 
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